Owners of process automation systems are subject to financial pressures to modernize their automation assets while minimizing the downtime involved in updating those assets. Those conflicting objectives are complicated by the fact that most legacy automation systems were designed to operate “as a whole,” but various pieces (or “subsystems”) of the system become obsolete at different rates. That leads to situations where the owner of an automation system may be eager to replace a 15 year-old operator console, but reluctant to replace a 15 year-old controller that the console operates.
Providers of automation control systems would happily sell a new system to customers piece by piece, but it is difficult to satisfy the replacement market at a reasonable price. Most vendors are not well positioned to swap out a “layer” in an automation system, such as an operator console, while leaving other layers, such as controllers, in place. In addition, legacy automation assets are often a hodge-podge of systems that have grown over time, so customer A may need a console replacement for system X, customer B needs a console replacement for system Y and customer C needs a console replacement that can work seamlessly with systems X and Z, while needing a new batch management system as well. In other words, upgrade scenarios are so diverse that there is no such thing as a “typical” upgrade.
A final complication is that customers tend to modernize their assets in order to obtain the integration benefits of a modern system, such as the integration of process automation data with enterprise level tools. Many of those high-level information systems were unavailable at the time that the legacy systems were conceived, and that means that there is no uniform, well-defined integration path for connecting the legacy system into a modern, enterprise-wide information system.
Despite the problems involved in automation system modernization, users do occasionally modernize pieces of their systems, although the rate of modernization is not what it could be, due to the great expense involved. Automation system upgrades are often ad-hoc replacements that require a substantial amount of engineering, a great deal of expense and a significant disruption of operations. The user often replaces more of a system than the user would like, because of the limited replacement options that most vendors provide. In some cases, vendors will create ad-hoc tools to assist in the task and in some cases there are even formal translation tools available. However, those tools are typically target-specific (e.g., a tool to integrate system X into vendor A's equipment, a tool to integrate system Y into vendor A's system and so forth). There are no known solutions available that offer a clean, uniform integration path into high-level information systems.
An object oriented framework has been used in providing interfaces in other problems involving disparate systems. For example, in U.S. Pat. No. 6,728,948 to Baxter et al., an object oriented framework mechanism is used in providing a generic order entry processing interface used in linking disparate order fulfillment systems. The interface creates and processes an order and generates requests to fill the order to one or more fulfillment systems.
There is therefore presently a need to provide a method and system for modernizing process automation assets while minimizing engineering costs and downtime. Particularly, there is a need for a technique for translating requirements of a legacy automation system to a set of parameters that may be used to configure a target automation subsystem for installation in the legacy system. To the inventors' knowledge, no such technique is currently available.